Git - multiple machines per developer - transfer through machines, but not the main branch

Question

We are moving on to git from SVN, and there are some concepts that I can’t get around.

We have the setup as follows:

• live server, "live"
• internal server-server, "local" (git server, svn daemon, all repositories are on this)
• workstations (iMacs)
• home computers (mainly Linux-PCs)

I converted our source to a git repository and passed it to "local". Everything works well, and when I clone it, it copies the main branch to my local environment, whether at home or at work. Pulling on a live server also works well, and it translates the main branch changes to the live environment. But I want to have the following features:

• I want to be able to develop and commit on a workstation without clicking on the main branch, but I would like these changes to be reflected on my home machine. In other words, I want to be able to do a partial update or function, perform and continue to work on it at home, without being involved in any living branch. Is this achieved with branching? What should I commit and then click on a specific branch? Keep in mind that tracking the git workstation repository on your home computer is out of the question since the workstation is not always turned on (anyone who has ever run a java application on a Mac knows that it can only stay for a couple of hours at most )

• I want every developer to be able to work on their part of the application, without us, depending on each other. Is it advisable to do this with branches-dev-branches, or should we create function branches?

• When the work on the function is completed, is it advisable to merge the branch into the master repo and then pull the main repo updates into the live environment, or do we have a separate branch of “production” for this purpose? How is live deployment typically handled via git? Since we have a release frequency of about 10 revisions per day (extremely fast development cycles), SVN has worked pretty well so far, since our live site is just a check of the repository and whenever the update is ready, we just called the svn update on these files are on a real server. Any recommendations on this with git?

Edit:

A practical example with my assumptions about how it all works: let our project be “project”, and we have developers “dev1”, “dev2” and “dev3”, each of which has 2 machines. The team has three tasks: “error”, “function” and “collaboration”. Error dev1, function dev2, and collaboration is a function that all three must work with together ($ REMOTE is the URL of the main repo on our local dev server, i.e. user @local: repo.git):

==========

I. Work locally

Since dev1 is assigned an "error", he will take care of this. He does the following:

$git branch bug $git checkout bug // switches to bug branch ( // edit some files) $git commit -a -m 'I fixed the bug!' $git push $REMOTE bug 

How does this developer now merge their fix into a master repo, and how does he remove the error branch on all computers after this merge is completed? I would like the error branch to disappear when people make an update or selection or something else if they checked it or, nevertheless, you checked it out.

========

II We work locally, and then continue on the same synchronized branch in another place

the "function" was assigned to "dev2", and he does this:

 $git branch feature $git checkout feature // switches to feature branch ( // edit/add some files etc. ) $git commit -a -m 'I made some updates, will continue at home' $git push $REMOTE feature // at home, the developer does the following, right? $git clone $REMOTE -b feature /some_new_folder // if he didn't clone the whole repo previously or cd previously_cloned_repo_master_or_whatever $git fetch $git checkout $REMOTE feature ( // right? ) ( // edit some files then ... ) $git commit -am 'I finished!' $git push // Same as above, what next? How to merge it into all other branches and safely delete the branch afterwards. What happens when someone is in a branch that has been deleted, and makes a pull? 

========

III Many people on the same branch, separate from the leading branch

“collaboration” is collaboration and will work with all three developers from all 6 locations. It is created by dev3.

 $git branch collaboration $git checkout collaboration // switches to needed branch ( // add something, so we have something to commit) $git commit -a -m 'Initialized new branch' $git push $REMOTE collaboration ( // The other two devs can then simply call .. ) $git fetch $git checkout $REMOTE collaboration ( // And they're ready to go, right? ) ( // Each dev then makes his own edits on some areas, commits, and pushes. All pushes change the content of the branch, so that if dev2 pushed and dev1 makes $git pull in the root of the project while on this branch, dev1 will get his changes, right? ) 

========

Also, is it possible to limit a branch to a specific branch creator? For example, I would like to see what dev1 did on an “error” before it removes it, but in case I want to make some of my own changes to this, I should NOT be allowed to do this, I should do it instead a stretch request for this branch, and dev1 will have to manually accept my changes - I would not have to click on this.

Answer 1

TL DR

Use git stream .

It will remove questions and automate some of the things you ask for. When you are familiar with git thread and branching, etc., you can easily select something differently - or manually.

Changes to be reflected on my home machine as well

On your imac push / pull to not-master and on your home computer, push / pull from a non-master.

Where "non-master" is any branch that you are currently working on.

On dev branches

Before you, your workflow should help, without hindering development. For instance. what if two developers collaborate on the same task - do you want to make them work in different industries? Function areas probably make more sense; there is nothing wrong with having user branches.

Separate production branch

However, you do this - your live application should pull it out of a well-known stable tag / branch and usually don’t directly click on the master , because breaking things is part of development, but hacking the code from which your live application will pull is what you absolutely want to avoid. You should be able to pull your live installation without any doubt, at any time, that you can pull the broken code. If you use the Continuous Integration Server server , you can easily automate merging with the development branch to handle if all tests pass and even automatically deploy.

When the branch is completed with

All doubts about the workflow are one and the same. when the branch is completed, you merge it into your main branch.

i.e.

 $ git branch working-on-this master $ git add ... $ git commit ... $ # rinse and repeat $ git push --set-upstream $REMOTE working-on-this 

And when the time comes:

 $ git checkout master $ git pull $ git merge working-on-this $ git push $ git branch -d working-on-this $ git push $REMOTE :working-on-this 

You do not explicitly delete all branches on other machines; however, any user can at any time execute:

 $ git branch --merged master 

which, if the branch is finished, will look like this:

 $ git branch --merged master master working-on-this $ git branch -d working-on-this 

This indicates that it can be safely removed. In any case, git branch -d triggers a warning and aborts if you try to delete a branch that is not merged with the branch you are in when you execute the command.

If you find that you have several remote branches that are thought to have already completed, you can clear them with one command:

 $ git remote prune -n origin 

The -n flag means that it will only report which branches it is going to delete - delete this flag to actually delete the obsolete deleted branches

If you have several developers working in the same branch (sharing) communication is key , do not rely on the workflow, actively talk about deleting things before leaving one of your teams working in a (presumably) completed branch.

Branch Lock Permissions Limit

Yes, you can do it, but do you really want it? You are better off using communications and conventions.

Some suggestions:

• anyone can create a remote branch
• nobody commits / merges with the master (only the lead developer does this)
• nobody removes the remote branch (only the lead developer does this)
• nobody trims the remote server (only the lead developer does this)

Anyone can do any of the above at any time, but believing that you trust your team as a whole, there is no reason to actually prohibit developers from stopping them from doing this - there will probably be times when they need to be ranked , and the rules prevent this, while the convention does not.

Answer 2

I want to be able to develop and accomplish.

Yes, this is achieved by branching. Initially, you push the entire branch from the workstation to "local", and then you can check the tracking branch at home if you want to continue working there.

I want every developer to be ..

I would recommend feature branches, not developer branches. This makes sense when several developers collaborate with a feature.

When the work on the function is completed, is it recommended.

This is a matter of taste. Usually we create the first release branch (I think many do), so we have a seam between real live material and things that need to be tested when the release branch is considered stable, we merge this branch into a master, and then it can live.

I don’t think there are any best practices. It depends on what you are doing, i.e. What kind of material are you developing. If you want to keep your git workflow, you can do it. Instead of "svn update" you do "git pull".

Answer 3

You can enter naming conventions for your branches and let them all live happily on local . For instance:

At work:

 work$ git branch -a master * user1/my-work remote/local/master remote/local/user1/my-work work$ git push local user1/my-work 

and at home:

 home$ git branch -a master * user1/my-work remote/local/master remote/local/user1/my-work home$ git pull local user1/my-work 

Each user is assigned a prefix for their branches, so local can serve as a central storage server.