This Series

Git bit-by-bit is a tutorial series covering the Source Control Management software Git. In the last post I covered everything you need to start using Git as-soon-as-possible. Today we're going to cover how to manage multiple sets of changes.

Vocabulary

1. Repository
   • Location where changes are tracked.
2. Commit
   • A set of changes to be recorded.
3. Branch
   • A collection of commits.
4. Tag
   • A string assigned by the user to identify a commit.
5. Merge
   • Combine the commits of one branch, into another.
6. Conflict
   • A file with two sets of changes, that are not in agreement.

Commands

For this section, you should have an empty repository with a single commit on the master branch. If you don't, please follow the commands in the last entry

user:~/project/tutorial$ git branch

• Lists all of the local branches that are being tracked.

user:~/project/tutorial$ git checkout -b <branch>

• Create a new branch with the name <branch>.

user:~/project/tutorial$ git checkout <branch>

• Switch to <branch>.

user:~/project/tutorial$ git tag "v0.0.1"

• Assigns a tag of "v0.0.1" to the last commit.

user:~/project/tutorial$ git checkout tags/<tag>

• Switch to the commit that was assigned <tag>

user:~/project/tutorial$ git merge <branch> --no-commit --no-ff

• Git will prepare to join the history of <branch> with the current branch. It will not commit it right away, allowing you to compare the incoming changes.

user:~/project/tutorial$ git merge <branch>

• Git will attempt to join the changes you created in <branch>, with the state of the current branch.
• If successful, it will automatically make a new commit containing <branch>'s changes.
• If Git cannot join the changes together, it will result in a merge conflict. This can fixed, by deciding which sets of changes you would like to have committed. The current branch, or <branch>.

More Information:

This entry covered the basics of maintaining multiple sets of changes within a git repository. How to create new branches, how to switch between branches, how to leave a friendly trial behind and how to combine different sets of changes. My number one tip with this would be, to not fear merge conflicts. It can be startling and/or worrying to have to pick between two sets of changes. But if you merge often, take your time resolving them, and verify that the fixes don't break existing code. You'll master it in no time.

Find me on Twitter | LinkedIn
Sponsor me on Github
Like the article? Buy me a coffee!