Introduction
Here is one possible team workflow! I'm not saying it's the ultimate way and those that do not follow will burn! Feel free to discuss it and/or patch it!
For simplicity's readings, i talk about master as of the final branch we need to merge into. It's just to simplify and give a name. You can, of course, translate this by replacing master by a release branch.
One possible workflow
Retrieve the repository needed
Clone this repository
Go to the desired folder to receive the clone of the repository
Exemple :
cd ~/repositories/pro/
Then clone the repository
git clone adress-of-the-repository
Example: #+BEGINSRC sh git clone https://ardumont@github.com/ardumont/my-org-files.git #+ENDSRC sh
We create a branch from master to develop our fix or our functionality.
git checkout -b trigram-user/branch-name
Example :
git checkout -b adu/doSomeStuff
You do your dev regularly, add the files and commit.
The graph will look like something like this:
Regularly, return to master to synchronize the source.
# Return to master git checkout master # Synchronize your local repository and your workspace # with the content of the distant repository git pull
If there were some changes inside the remote master (origin/master), the graph will evolve like this:
Why does git refuse to checkout my branch?
If it refuses (git explains everything it does and also why it refuses), you may have forgotten one step. You may, for example, have changes locally that you did not commit to your index.
So, before returning to master, make sure that :
- you have commited everything in your index for your branch
git add the-thing-you-wanna-commit-but-unstable another-thing-to-commit-but-unstable ... git commit -m "Filthy commit not stable, need to amend it later" # later, when everything is ok # git add the-thing-you-wanna-commit-stable \ # another-thing-to-commit-stable ... # amend the commit # git commit --amend
- or dropped it if it is useless to you
rm the-thing-you-wanna-commit-but-unstable another-thing-to-commit-but-unstable ...
- or another option, stash it!
git stash # and later when everything is ok, just unstash it # git stash pop
Remark 2: These commands are your best friends, ask them to help you out!
git status
and/or
gitk --all
and/or
git log
Now, we're synchronized with master, we return to our branch and merge these changes inside our branch.
Return to our branch
git checkout trigram-user/branch-name
Merge the content of master into our branch
git merge master
Everything ok ? If everything is merging without problems, the graph will look like this:
There were conflicts, what do i do?
So there were conflits during merge, we must fix these conflicts manually.
Either you use the tool git offers you
git mergetool
(I do not detail because i didn't try yet!)
Or, you open your favourite editor or ide and choose what you want to keep or not depending on the situation. When all conflicts are resolved and that all your tests are ok, add all the files modified to the index, commit and that's all folks!
git status git add yourFileModified yourFile2Modified git commit
In either case of conflict or not, the branch will look like previously.
Why must i merge master into my branch ?
To make sure that what you're doing is still compatible with the latest code!
If you do not, you may break the code from master when you merge your fix or dev of the branch into master! It's what i think can protect the master!
What if master is broken ?
It depends on the policy of your project.
I've done my dev, what do i do ?
Check these assertions :
Is all your code commited to your branch?
Is your dev done?
Are all your unit-tests ok?
Are all your functional-tests or integration-tests ok?
Does your app deploy and work as expected?
Ok then, it's time to merge into master.
Return to master
git checkout master
To avoid some later merging, check you're up-to-date with master
git pull
If everything is already up-to-date, then pass to the next step. Else, return to the previous step of merging master into your branch.
Merge the content of the "merging branch" into master
git merge trigram-user/branch-name
At this point, it will only do a fast forward, that's just a moving forward the master pointer to the last commit of your branch (because your master branch did not advance between your checkout and the merge command).
So the graph will look like this:
Send your modifications to master!
git push
What if there are problems ?
It's not a real problem, it just means "somebody, somebody put something in your drink"! It means really that someone pushed something before you did finish your merge.
You must once again merge. But this time, it will be fast. As your branch and the master are already merged, when you will pull some code, git will automagically merge what it can from master and leave you eventuals conflicts to resolve.
# synchronize with everybody... (needs somebody to love!) git pull # fix eventual merge conflicts and check your tests # add the merged files to the index (git add) # and commit (git commit) git push