Date: Thu, 28 Mar 2024 05:25:55 -0400 (EDT) Message-ID: <2063197839.27322.1711617955676@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_27321_1968140447.1711617955676" ------=_Part_27321_1968140447.1711617955676 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
When it comes to talking about git best practices, a lot of peop= le seem to point toward the git-flow bran= ching model. Personally, there are things I like about it (hotfix branc= hes) and things I can't get past (a preference for merge commits..ewww). I = think with some tweaks, it could be a reasonable model for medium to large = development teams. But I tend to work with small teams and I don't have act= ual experience with git-flow, so I'm going to stop talking about that.
Here's what I do have experience with: How I Use Git
Contents:
master
branch is li=
ke subversion's trunk
. Successful projects tend to keep these =
in a state where releases can be made with minimal effort. Therefore, only =
code that has been fully tested is allowed in.MYPROJ-42
, name the branch mypr=
oj-42
.=
git branch -d branchname
. To remove a remote branch, git push =
origin :branchname
.v1.0.0
". I like this convention (i=
ncluding the trailing zero) because the Major.Feature.Bugfix convention is =
compatible with semantic versioning and is commonly seen with Maven artif=
acts.= p>
Merge commits are ugly. Nobody likes them and they smell funny. Here are= some tips for avoiding them:
git pull
to get remote changes, if you have =
any local commits that haven't been pushed yet (wait, you're not workin=
g directly on master, are you?), specify --rebase
(you ca=
n also make this the default option as explained in this article). This will modify the sequence of =
commits to your local repository so that your locally-committed changes app=
ear after those you just pulled. Now when you push your changes, y=
our fellow committers will just see an incremental set of changes with your=
s at the end, and it will make sense to them.git merge yourbranch
, by default, g=
it will attempt to do a fast-forward commit if possible. It's not possible =
if there are any changes in master that aren't already in your branch. In t=
his case, before attempting to merge your changes into master, switch to yo=
ur branch and type git rebase master
. This will put all the ne=
w commits from master in your branch, behind your changes. Now it =
should be possible to fast-forward merge your branch into master by switchi=
ng to master and typing git merge yourbranch
git pull --rebase<=
/code> or a git rebase master
will fail due to a conflict. In =
that case, see this excellen=
t article, which covers resolving rebase conflicts.
<= /p>
Before pushing the changes from an issue branch to the origin master bra= nch, it's useful to be able to do a little surgery on them so they make mor= e sense to others. Squashing commits allows you to turn a high number of co= mmits into a low number, with the same resulting code. The sequence of comm= its get "squashed" into a smaller number of commits. Re-wording lets you co= mpletely change the commit message for any number of commits.
You can use an interactive rebase to do one or both of these. Let's say = you're on a branch and you want to squash the last 3 commits into one and r= eword the commit message. First, run:
git rebase -i HEAD~3
The editor will come up and basically guide you through the rest of the = process. In this case, you'll want to change the first line to begin with "= r" (reword) and the following two lines to begin with "s" (squash into prev= ious commit).
If there's a tracked issue associated with your commit (ideal):
MYPROJ-42: Feature/bug description under 50 chars if possible Longer description, if needed. Don't exceed 72 lines here. A blank line between sections is ok if multiple sections of text are needed. https://example.org/path/to/tracker/MYPROJ-42
Otherwise (it's a small change/typo fix, etc.):
Fix testing errors introduced by last commit
Notice the following conventions:
After using git for a little over a year, here are a few (Unix-based) to= ols I've settled on.