a 'git' conundrum that i don't git !

[ajoo]

Hi, 

 

I am using the git for versioning a project running on a VM running linux. I have made n number of commits on the remote repo in bitbucket. 

 

Now I wish to develop the same project on another VM running linux and the aws beanstalk(EB) library/package. So while the code is same the environments are different. There are EB related folders on the aws eb machine that are not there on the first VM. I don't want to mix the two since that would surely result in a lot of confusion.

 

I can keep the two ( or can i ?) on two separate branches from here on but then the code that is being modified on one branch is not available on the other !!!??? But this would make it difficult or rather impossible to develop the code in both branches simultaneously. i.e. if I make changes to the code in the 2nd VM, it would not reflect in the code in the 1st VM and vice versa. I would have to copy code from the 2nd VM and manually paste it into the 1st VM and then commit to that branch and while that can work, If I made n changes to reach at a certain functionality,I would lose the intermediate changes , in the 1st VM,  that i made in the 2nd VM to reach where it is.

 

Is there any way to keep the code same simultaneously in both branches? If not then would it not be better simply create a fresh repository instead of a branch ?

 

hmmm !!  It's kind of confusing so I hope I am able to explain this sanely enough to make sense to the gurus !

 

Thanks all !

Edited September 21, 2017 by ajoo

[requinix]

You can't use git to keep files on two separate machines the same. It's not a file-sharing system.

 

If you want the same content in both machines then find a file-sharing system to do it. Like Dropbox.

 

But if you're using two different branches, like logically they're two branches for two different things, then either (a) they need to be developed separately until they're ready to commit to the "main" remote repo, at which point the other needs to pull down the changes and deal with conflicts, or (b) you're abusing the concept of branches.

 

I'm kinda thinking the latter.

[ajoo]

Hi requinix !

 

Thanks for the response. 

 

 

 

if you're using two different branches, like logically they're two branches for two different things,

Not really. The code is going to be the same. The project and folder structures is going to be the same as well. It's just that some of the folders are extra that EB generates and the deployment techniques for the two are different.

 

Maybe I can rethink this some more and try out a few things and revert. Maybe you can come up with some idea too !!

 

Thanks !

[requinix]

What I don't get is why you're doing development on these machines when it sounds like they're deployment targets? You can have the git repo there but your development should be somewhere else, and when you're done with a change you push to remote and then have both boxes pull down the changes.

[kicken]

Generally one doesn't track environment specific stuff like configuration files, caches, etc. You'd ignore those files/folders so each environment can have it's own version without causing conflicts. For things like config files you could add a template/example config to your repository that one copies then modifies to create the actual config file.

 

If for some reason you do want to version them, you could make a branch for each of your environments. Whenever you finish some development task that you want to push out to the different environments you'd merge the changes from master into each of the environment branches then update your different systems.

[ajoo]

Hi requinix,

 

I am not sure what you mean. I would just like to clarify.

 

 

 

What I don't get is why you're doing development on these machines... 

Which machines are you referring to ? aws or the VM's ?

 

 

 

You can have the git repo there ..

Where ? My repository is on bitbucket.

 

 

 

 but your development should be somewhere else ...

 

Like where do you mean ?

 

Sorry but I am totally confused by your reply.  

 

Thanks !

 

P.S. Hi Kicken, just saw your reply. Thanks ! Will revert soon. 

Edited September 21, 2017 by ajoo

[gizmola]

You should not be versioning libraries and things that aren't code you've written for your system. Having those in place on the server is the job of composer and/or other deployment tools.

[requinix]

Which machines are you referring to ? aws or the VM's ?

The ones that have the git clones you're modifying. Apparently that's the VMs.

 

Where ? My repository is on bitbucket.

...okay, so you don't have clones on the VMs?

 

Like where do you mean ?

Not on the machines that are supposed to be running the code. Like your dev machine/environment.

[ajoo]

Hi guys ! thanks for all the replies. 

 

@requinix. I think i understand now your previous reply in #4. 

 

I am using the VMs for both development and deployment on aws using aws cli. I can do the development on the VM, test my code there and if I think its ok, i can commit it and then deploy it from there to the aws which would be the production server. Right now I am only testing and trying out. You see any flaw in that?

 

The thing is that I started off using a single VPS model and had my DB etc all on one server. I developed code on the VM ,committed changes to the local machine and then pushed it to the remote repo on bitbucket. I could then deploy the code to aws from the bitbucket repo. This was the first VM. It also has code for provisioning the server and the DB which is not there if I use EB.

 

Then, as advised by some of you guys, I decided to use the elastic beanstalk (EB) on aws that separates the database from the web server.  It has a different deployment procedure as I explained in the first para above. namely, make changes, test locally, commit and the use the deploy from there itself using the cli. It does not require me to push the changes to bitbucket.

 

@All

 

The EB creates some folder with environment configuration information which should be versioned as well. These do not contan any libraries etc. as Gizmola pointed. So I am not versioning any of them. 

 

@Kicken : That does seem like a good solution had I started off with it. Now after about 40 odd commits, i think it would be a bit difficult. I'll, however, still give it a go maybe. 

 

Thanks !

[requinix]

I am using the VMs for both development and deployment on aws using aws cli. I can do the development on the VM, test my code there and if I think its ok, i can commit it and then deploy it from there to the aws which would be the production server. Right now I am only testing and trying out.

Then you should treat it like it was development on two separate branches - like two developers working on two machines. Either

a) Pick one VM, do whatever dev work you need and then commit+push the finished product. Don't leave it part-way through to go work on the other VM. When you do begin work on the other VM, first do a pull to get the changes from earlier.

b) Go ahead and do work on both VMs, but the work you do on one shouldn't affect the other. If you need a shared feature/change then do (a) to finish it. Otherwise you have to deal with (potential) conflicts: when one VM is finished, push, then pull on the other and do a merge.