We’re currently using git and I tried to come up with a reasonable workflow for people to use, but there’s currently one issue that I’m not sure how to resolve. If there is a conflict when we do the merge back into the master branch, we lose the history in the squashed commit message, which is something we want to keep. The current workflow is below:
git pull– This should be done on the master branch.git checkout -b TASK-ID– Create a new branch for the task. TASK-ID would be something like TASK-101- Work on the task and commit changes as needed.
- When done with the task,
git checkout master git pull– Get any changes that have been made since the last pull.- Resolve any conflicts and ensure the current version in the master compiles.
git merge --squash TASK-ID– This treats all of the commits in the branch as one commit when merging.git commit– Add any additional information, specifically the TASK-ID, to the commit message. It should be noted that all commit messages from the branch are included, so they were not lost when the merge occurred.git push– Push the changes back to the server.
Some background: there are not a lot of us working on this currently, we don’t see conflicts very often. The reason for the squashed commit is so that we have one commit for each task. This way if our Bamboo server finds a problem with a build, we can easily tie it back to a task and have the developer fix it. Also, it keeps the master history cleaner because I, at least, tend to make a lot of commits. Yes, I know this may have to change if we start dealing with larger teams, but that’s in the future.
Now, I do realize that in this case, we can simply do the pull after the merge, however that doesn’t completely solve the issue since there’s a chance that one of our developers may have to switch branches temporarily to fix an issue or work on a higher priority. What I would love to see is how we can achieve what I’m getting now without losing the commit history in the squashed merge. I’ve looked into several solutions using rebase, but none of them were quite what I was looking for.
So, to summarize, the requirements I have are:
- Clean history in the master
- Can see the changes in the branch in the message for a single commit
- The commit message for the squashed commit needs to be edited to have the task ID in it before committing the change. (Amending could work as well).
Maybe I misunderstood, but what I normally do is keep my master always equal or behind the master from origin.This way, when I do a git pull, it never has any merges to do (since history of the master is never overwritten in my team).
After I do a git pull, I go to the branch TASK-101 and merge the results of the master into this branch. So task-101 will have my commits, the commits that are in master, and possibly a merge commit. I can do this every time I feel the need to update my working repo.
When I’m ready to commit, I do this one last time, and then I go to master and squash merge the commit from task-101, and do a dcommit afterwards, to avoid the probability of conflicts because the time window between the last pull and the push is very small.(it never happened once in my team. If it happens. if it ever happens, I will probably have to notify the team and rewrite history).